<html>
<!--
 Copyright (C) 2014, 2015, 2017, 2019, 2020, 2021 XStream committers.
 All rights reserved.
 
 The software in this package is published under the terms of the BSD
 style license a copy of which has been included with this distribution in
 the LICENSE.txt file.
 
 Created on 09. January 2014 by Joerg Schaible
 -->
  <head>
    <title>Security Aspects</title>
  </head>

  <body>
	<p>XStream is designed to be an easy to use library.  It takes its main task seriously: converting Java objects to
	XML, and XML to Java objects. As a result, it is possible to create an instance of XStream with the default
	constructor, call a method to convert an object into XML, then call another method to turn the XML back into an
	equivalent Java object.  By design, there are few limits to the type of objects XStream can handle.</p>
 
	<p class=highlight>Note: XStream supports other data formats than XML, e.g. JSON. Those formats can be used for
	the same attacks.</p>
 	
	<p>This flexibility comes at a price.  XStream applies various techniques under the hood to ensure it is able to
 	handle all types of objects.  This includes using undocumented Java features and reflection.  The XML generated by
 	XStream includes all information required to build objects of almost any type.  This introduces a potential
 	security problem.</p>
 
	<p>The provided XML data is used by XStream to unmarshal Java objects.  This data can be manipulated by injecting
	the XML representation of other objects, that were not present at marshalling time.  An attacker could take
	advantage of this to access private data, delete local files, execute arbitrary code or shell commands in the
	context of the server running the XStream process or cause a denial of service by crashing the application or
	manage to enter an endless loop consuming 100% of CPU cycles.</p>
 
	<p>Note, that the XML data can be manipulated on different levels.  For example, manipulating values on existing
 	objects (such as a price value), accessing private data, or breaking the format and causing the XML parser to fail.
 	The latter case will raise an exception, but the former case must be handled by validity checks in any application
 	which processes user-supplied XML.</p>

    <h2 id="CVEs">Documented Vulnerabilities</h2>

    <p>Over the years, several of these attacks have been reported and documented in the Common Vulnerability and
    Exposure (CVE) system managed by the <a href="http://www.mitre.org/">Mitre Corporation</a>. Following a list of the
    reported vulnerabilities for the different versions:</p>
    
    <table summary="Table of reported vulnerabilities documented as CVE">
      <tr>
        <th>CVE</th>
        <th>Description</th>
      </tr>
      <tr>
        <th>Version 1.4.16</th>
        <td></td>
        <td></td>
      </tr>
      <tr>
        <th><a href="CVE-2021-29505.html">CVE-2021-29505</a></th>
        <td>XStream is vulnerable to a Remote Command Execution attack.</td>
      </tr>
      <tr>
        <th>Version 1.4.15</th>
        <td></td>
        <td></td>
      </tr>
      <tr>
        <th><a href="CVE-2021-21341.html">CVE-2021-21341</a></th>
        <td>XStream can cause a Denial of Service.</td>
      </tr>
      <tr>
        <th><a href="CVE-2021-21342.html">CVE-2021-21342</a></th>
        <td>A Server-Side Forgery Request can be activated unmarshalling with XStream to access data streams from an
        arbitrary URL referencing a resource in an intranet or the local host.</td>
      </tr>
      <tr>
        <th><a href="CVE-2021-21343.html">CVE-2021-21343</a></th>
        <td>XStream is vulnerable to an Arbitrary File Deletion on the local host when unmarshalling as long as the
        executing process has sufficient rights.</td>
      </tr>
      <tr>
        <th><a href="CVE-2021-21344.html">CVE-2021-21344</a></th>
        <td>XStream is vulnerable to an Arbitrary Code Execution attack.</td>
      </tr>
      <tr>
        <th><a href="CVE-2021-21345.html">CVE-2021-21345</a></th>
        <td>XStream is vulnerable to a Remote Command Execution attack.</td>
      </tr>
      <tr>
        <th><a href="CVE-2021-21346.html">CVE-2021-21346</a></th>
        <td>XStream is vulnerable to an Arbitrary Code Execution attack.</td>
      </tr>
      <tr>
        <th><a href="CVE-2021-21347.html">CVE-2021-21347</a></th>
        <td>XStream is vulnerable to an Arbitrary Code Execution attack.</td>
      </tr>
      <tr>
        <th><a href="CVE-2021-21348.html">CVE-2021-21348</a></th>
        <td>XStream is vulnerable to an attack using Regular Expression for a Denial of Service (ReDos).</td>
      </tr>
      <tr>
        <th><a href="CVE-2021-21349.html">CVE-2021-21349</a></th>
        <td>A Server-Side Forgery Request can be activated unmarshalling with XStream to access data streams from an
        arbitrary URL referencing a resource in an intranet or the local host.</td>
      </tr>
      <tr>
        <th><a href="CVE-2021-21350.html">CVE-2021-21350</a></th>
        <td>XStream is vulnerable to an Arbitrary Code Execution attack.</td>
      </tr>
      <tr>
        <th><a href="CVE-2021-21351.html">CVE-2021-21351</a></th>
        <td>XStream is vulnerable to an Arbitrary Code Execution attack.</td>
      </tr>
      <tr>
        <th>Version 1.4.14</th>
        <td></td>
      </tr>
      <tr>
        <th><a href="CVE-2020-26258.html">CVE-2020-26258</a></th>
        <td>A Server-Side Forgery Request can be activated unmarshalling with XStream to access data streams from an
        arbitrary URL referencing a resource in an intranet or the local host.</td>
      </tr>
      <tr>
        <th><a href="CVE-2020-26259.html">CVE-2020-26259</a></th>
        <td>XStream is vulnerable to an Arbitrary File Deletion on the local host when unmarshalling as long as the
        executing process has sufficient rights.</td>
      </tr>
      <tr>
        <th>Version 1.4.13</th>
        <td></td>
      </tr>
      <tr>
        <th><a href="CVE-2020-26217.html">CVE-2020-26217</a></th>
        <td>XStream can be used for Remote Code Execution.</td>
      </tr>
      <tr>
        <th>Version 1.4.9</th>
        <td></td>
      </tr>
      <tr>
        <th><a href="CVE-2017-7957.html">CVE-2017-7957</a></th>
        <td>XStream can cause a Denial of Service when unmarshalling void.</td>
      </tr>
      <tr>
        <th>Version 1.4.8</th>
        <td></td>
      </tr>
      <tr>
        <th><a href="CVE-2016-3674.html">CVE-2016-3674</a></th>
        <td>XML External Entity (XXE) Vulnerability in XStream.</td>
      </tr>
      <tr>
        <th>Version 1.4.6 (and 1.4.10)</th>
        <td></td>
      </tr>
      <tr>
        <th><a href="CVE-2013-7285.html">CVE-2013-7285</a></th>
        <td>XStream can be used for Remote Code Execution.</td>
      </tr>
    </table>
    
    <p>See <a href="#workaround">workarounds</a> for the different versions covering all the CVEs listed here.</p>

	<p class="hightlight">This list contains only vulnerabilities, that could be created using the Java runtime with
	XStream.  Vulnerabilities introduced by using additional 3rd party libraries and classes are beyond XStream's
	responsibility.</p>
     
    <h2 id="external">External Security</h2>

	<p>An active Java Security Manager can prevent actions required by XStream components or converters.  The same
	applies to environments such as Google Application Engine.  XStream tries to some extent to check the functionality
	of a converter before it claims to handle a type.</p>
         
	<p>Therefore it is possible that XStream behaves differently in such an environment, because a converter suddenly
 	no longer handles a special type or any type at all.  It is essential that an application that will have to run in
 	such an environment is tested at an early stage to prevent nasty surprises.</p>
      
    <h2 id="implicit">Implicit Security</h2>
	
	<p>As explained above, it is possible to inject other object instances if an attacker is able to define the data
	used to deserialize the Java objects, see the different CVEs.  Knowing how to define such an attack is the only
	prerequisite.</p>
         
 	<p>All those scenarios were based on types that are delivered with the Java runtime at some version.  Looking at 
 	other well-known and commonly used Java libraries libraries such as ASM, CGLIB, or Groovy, you will have to assume
 	other scenarios for exploits as well.  A class like InvokerTransformer of Apache Commons Collections has a high
 	potential for attacks.   By default XStream 1.5 works now with a whitelist.  If you modify the default setup, it
 	is also your responsibility to protect your clients from such vulnerabilities.</p>
         
	<p>Note: This vulnerability is not even a special problem of XStream.  XML being deserialized by XStream acts here
	like a script, and the scenario above can be created with any script that is executed within a Java runtime (e.g.
	using its JavaScript interpreter) if someone is able to manipulate it externally.  The key message for application
	developers is that deserializing arbitrary user-supplied content is a dangerous proposition in all cases. The best
	approach to prevent such an attach is a <a href="#example">whitelist</a>, i.e. the deserialization mechanism should
	only allow explicit types. See also the advice for vulnerabilities using
	<a href="https://docs.oracle.com/javase/10/core/serialization-filtering1.htm">Java Serialization</a>.</p>

	<p class="hightlight">A blacklist for special classes only creates therefore a scenario for a false security,
    because no-one can assure, that no other vulnerability is found.  A better approach is the usage of a whitelist
    i.e. the allowed class types are setup explicitly. This is the default for XStream 1.5.x (see below).</p>
    
    <h2 id="explicit">Explicit Security</h2>
    
	<p>Starting with XStream 1.4.7, it is possible to define <a href="#framework">permissions</a> for types, to check
	the type of an object that should be unmarshalled.  Those permissions can be used to allow or deny types explicitly
	With these permissions it is at least not possible to inject unexpected types into an object graph.  The security
	framework supports the setup of a blacklist or whitelist scenario.  Any application should use this feature to
	limit the danger of arbitrary command execution if it deserializes data from an external source.</p>
	
	<p>XStream itself sets up a whitelist by default, i.e. it blocks all classes except those types it has explicit
	converters for.  Nonetheless, it is still the better approach to maintain an own whitelist for an XStream
	instance.  A blacklist scenario should be avoided in general, because it provides a false sense of security.</p>

	<p class=highlight>Note:  If a type on a whitelist contains itself other members that are handled by XStream, you
	will have to add those member's types to the whitelist also.  There is no automatism for indirect references.</p>
         
	<p>Separate to the XStream security framework, it has always been possible to overwrite the setupConverter method
	of XStream to register only the required converters.</p>
         
	<p class=highlight>Apart from value manipulations, this implementation still allows the injection of allowed
	objects at wrong locations, e.g. inserting an integer into a list of strings.</p>
    
    <h2 id="validation">XML Validation</h2>

	<p>XML itself supports input validation using a schema and a validating parser.  With XStream, you can use e.g. a
	DOM parser for validation, but it will take some effort to ensure that the XML read and written by XStream matches
	the schema in first place, because XStream uses additionally own attributes.  Typically you will have to write some
	custom converters, but it can be worth the effort depending on the use case.</p>

    <h1 id="framework">Security Framework</h1>

	<p>Noted above, it might be possible that other combinations are found with the Java runtime itself, or other
	commonly-used Java libraries that allow a similar vulnerability like the known case using the Java Beans
	EventHandler.  To prevent such a possibility at all, XStream version 1.4.7 and above contains a security framework,
	allowing application developers to define which types are allowed to be unmarshalled with XStream.</p>
         
	<p>The core interface is <a href="javadoc/com/thoughtworks/xstream/security/TypePermission.html">TypePermission</a>.
	The <a href="javadoc/com/thoughtworks/xstream/mapper/SecurityMapper.html">SecurityMapper</a> will evaluate a list
	of registered instances for every type that will be required while unmarshalling input data.  The interface has one
	simple method:</p><div class="Source Java"><pre>boolean allow(Class&lt;?&gt;);</pre></div>
         
	<p>The <a href="javadoc/com/thoughtworks/xstream/XStream.html">XStream</a> facade provides the following methods to
	register such type permissions within the SecurityMapper:</p><div class="Source Java">
<pre>XStream.addPermission(TypePermission);
XStream.allowTypes(Class&lt;?&gt;...);
XStream.allowTypes(String...);
XStream.allowTypesByRegExp(String...);
XStream.allowTypesByRegExp(Pattern...);
XStream.allowTypesByWildcard(String...);
XStream.allowTypeHierary(Class&lt;?&gt;);
XStream.denyPermission(TypePermission);
XStream.denyTypes(Class&lt;?&gt;...);
XStream.denyTypes(String...);
XStream.denyTypesByRegExp(String...);
XStream.denyTypesByRegExp(Pattern...);
XStream.denyTypesByWildcard(String...);
XStream.denyTypeHierary(Class&lt;?&gt;);</pre></div>

	<p>The sequence of registration is essential. The most recently registered permission will be evaluated first.</p>
         
	<p>Every TypePermission has three options to implement the allow method and make decisions on the provided type:<p>
	<ul>
	<li>if the method returns <i>true</i>, the type is accepted and no other permissions are evaluated</li>
	<li>if the method returns <i>false</i>, the implementation cannot judge over the type and the SecurityMapper will
	continue with the next permission instance in its registration list</li>
	<li>the method throws a <a href="javadoc/com/thoughtworks/xstream/security/ForbiddenClassException.html">ForbiddenClassException</a>
	to stop the unmarshalling process</li>
	</ul>
         
    <h2 id="predefined">Predefined Permission Types</h2>

	<p>XStream provides some TypePermission implementations to allow any or no type at all, to allow primitive types
	and their counterpart, null, array types, implementations match the name of the type by regular or wildcard
	expression and one to invert a permission.</p>
	
	<table class="examplesTable" summary="Overview over all type permissions delivered with XStream">
	<!-- .................................................................................................. -->
	<tr>
	    <th>Permission</th>
	    <th>Description</th>
	    <th width="33%">Example</th>
	    <th width="33%">Default</th>
	</tr>
	<tr>
	    <td><a href="javadoc/com/thoughtworks/xstream/security/AnyTypePermission.html">AnyTypePermission</a></td>
	    <td><b>Start a blacklist</b> and allow any type.  A registration of this permission will wipe any prior one.
	    You may use the ANY instance directly.  Note, that it is now in the responsibility of the developer to deny any
	    type that might be used for arbitrary code execution as described in the CVEs above.</td>
	    <td>addPermission(<i>AnyTypePermission.ANY</i>);</td>
	    <td>no</td>
	</tr>
	<tr>
	    <td><a href="javadoc/com/thoughtworks/xstream/security/ArrayTypePermission.html">ArrayTypePermission</a></td>
	    <td>Allow any array type.  You may use the ARRAYS instance directly.</td>
	    <td>addPermission(<i>ArrayTypePermission.ARRAYS</i>);</td>
	    <td>yes</td>
	</tr>
	<tr>
	    <td><a href="javadoc/com/thoughtworks/xstream/security/CGLIBProxyTypePermission.html">CGLIBProxyTypePermission</a></td>
	    <td>Allow any CGLIB proxy type.  You may use the PROXIES instance directly.</td>
	    <td>addPermission(<i>CGLIBProxyTypePermission.PROXIES</i>);</td>
	    <td>no</td>
	</tr>
	<tr>
	    <td><a href="javadoc/com/thoughtworks/xstream/security/ExplicitTypePermission.html">ExplicitTypePermission</a></td>
	    <td>Allow types explicitly by name.</td>
	    <td>allowTypes(new String[] {"<i>java.io.File</i>", "<i>java.lang.ProcessBuilder</i>"});<br/>
	    allowTypes(new Class[] {<i>java.io.File.class</i>, <i>java.lang.ProcessBuilder.class</i>});</td>
	    <td>java.io.File, java.nio.charset.Charset, java.util.BitSet, java.lang.Class, java.lang.Object,
	    java.lang.StackTraceElement, java.lang.String, java.lang.StringBuffer, java.lang.StringBuilder, java.net.URI,
	    java.net.URL, java.sql.Date, java.sql.Time, java.sql.Timestamp, java.text.DecimalFormatSymbols,
	    java.time.Duration, java.time.Instant, java.time.LocalDate, java.time.LocalDateTime, java.time.LocalTime,
	    java.time.MonthDay, java.time.OffsetDateTime, java.time.OffsetTime, java.time.Period, java.time.Ser,
	    java.time.Year, java.time.YearMonth, java.time.ZonedDateTime, java.time.chrono.HijrahDate, 
	    java.time.chrono.JapaneseDate, java.time.chrono.JapaneseEra, java.time.chrono.MinguoDate, java.time.chrono.Ser,
	    java.time.chrono.ThaiBuddhistDate, java.time.temporal.ValueRange, java.time.temporal.WeekFields,
	    java.util.Currency, java.util.Date, java.util.Locale, java.util.regex.Pattern, java.util.UUID</td>
	</tr>
	<tr>
	    <td><a href="javadoc/com/thoughtworks/xstream/security/InterfaceTypePermission.html">InterfaceTypePermission</a></td>
	    <td>Allow any interface type.  You may use the INTERFACES instance directly.</td>
	    <td>addPermission(<i>InterfaceTypePermission.INTERFACES</i>);</td>
	    <td>yes</td>
	</tr>
	<tr>
	    <td><a href="javadoc/com/thoughtworks/xstream/security/NoPermission.html">NoPermission</a></td>
	    <td>Invert any other permission.  Instances of this type are used by XStream in the deny methods wrapping a permission.</td>
	    <td>denyPermission(<i>permissionInstance</i>);</td>
	    <td>no</td>
	</tr>
	<tr>
	    <td><a href="javadoc/com/thoughtworks/xstream/security/NoTypePermission.html">NoTypePermission</a></td>
	    <td><b>Start a whitelist</b> and allow no type.  A registration of this permission will wipe any prior one.
	    You may use the NONE instance directly.</td>
	    <td>addPermission(<i>NoTypePermission.NONE</i>);</td>
	    <td>yes</td>
	</tr>
	<tr>
	    <td><a href="javadoc/com/thoughtworks/xstream/security/NullPermission.html">NullPermission</a></td>
	    <td>Allow null as type.  You may use the NULL instance directly.</td>
	    <td>addPermission(<i>NullPermission.NULL</i>);</td>
	    <td>yes</td>
	</tr>
	<tr>
	    <td><a href="javadoc/com/thoughtworks/xstream/security/PrimitiveTypePermission.html">PrimitiveTypePermission</a></td>
	    <td>Allow any primitive type and its boxed counterpart (excluding void).  You may use the PRIMITIVES instance
	    directly.</td>
	    <td>addPermission(<i>PrimitiveTypePermission.PRIMITIVES</i>);</td>
	    <td>yes</td>
	</tr>
	<tr>
	    <td><a href="javadoc/com/thoughtworks/xstream/security/ProxyTypePermission.html">ProxyTypePermission</a></td>
	    <td>Allow any Java proxy type.  You may use the PROXIES instance directly.</td>
	    <td>addPermission(<i>ProxyTypePermission.PROXIES</i>);</td>
	    <td>no</td>
	</tr>
	<tr>
	    <td><a href="javadoc/com/thoughtworks/xstream/security/RegExpTypePermission.html">RegExpTypePermission</a></td>
	    <td>Allow any type that matches with its name a regular expression.</td>
	    <td class="example">allowTypeByRegExp(new String[]{"<i>.*\\.core\\..*</i>", "<i>[^$]+</i>"});<br/>
	    allowTypeByRegExp(new Pattern[]{Pattern.compile("<i>.*\\.core\\..*</i>"), Pattern.compile("<i>[^$]+</i>")});</td>
	    <td>&ndash;</td>
	</tr>
	<tr>
	    <td><a href="javadoc/com/thoughtworks/xstream/security/TypeHierarchyPermission.html">TypeHierarchyPermission</a></td>
	    <td>Allow types of a hierarchy.</td>
	    <td>allowTypeHierarchy(<i>java.lang.Throwable.class</i>);</td>
	    <td>java.lang.Enum, java.lang.Number, java.lang.Throwable, java.lang.reflect.Member, java.nio.file.Path,
	    java.time.Clock, java.time.ZoneId, java.time.chrono.Chronology, java.util.Calendar, java.util.Collection,
	    java.util.Map, java.util.Map.Entry, java.util.TimeZone</td>
	</tr>
	<tr>
	    <td><a href="javadoc/com/thoughtworks/xstream/security/WildcardTypePermission.html">WildcardTypePermission</a></td>
	    <td>Allow any type that matches with its name a wildcard expression.</td>
	    <td>allowTypeByWildcard(new String[]{"<i>java.lang.*</i>", "<i>java.util.**"</i>});</td>
	    <td>&ndash;</td>
	</tr>
    </table>

    <h2 id="example">Example Code Whitelist</h2>

	<p>XStream uses the default permissions from the table above.  You may either clear out this default
	and register your own permissions to activate the security framework simply add your own permissions on top of it
	(the Blog type is from the 	<a href="alias-tutorial.html">Alias Tutorial</a>):</p>

<div class="Source Java"><pre>XStream xstream = new XStream();
// clear out existing permissions and start a whitelist
xstream.addPermission(NoTypePermission.NONE);
// allow some basics
xstream.addPermission(NullPermission.NULL);
xstream.addPermission(PrimitiveTypePermission.PRIMITIVES);
xstream.allowTypeHierarchy(Collection.class);
// allow any type from the same package
xstream.allowTypesByWildcard(Blog.class.getPackage().getName()+".*");
</pre></div>

    <p>You may have a further look at XStream's acceptance tests, the security framework is enabled there in general.</p>
         
    <h2 id="workaround">Workarounds for older XStream versions</h2>

    <p>As recommended, use XStream's security framework to implement a whitelist for the allowed types. This is
    possible since XStream 1.4.7 and the default since XStream 1.5.0:</p>
<div class="Source Java"><pre>XStream xstream = new XStream();
// add your allowed types, type hierarchies or packages here
</pre></div>
    <p>Users of XStream 1.4.16 who insist to use XStream default blacklist - despite that clear recommendation - can
    add these lines to XStream's setup code:</p>
<div class="Source Java"><pre>xstream.denyTypesByRegExp(new String[]{ ".*\\.Lazy(?:Search)?Enumeration.*", "(?:java|sun)\\.rmi\\..*" });
</pre></div>
    <p>Users of XStream 1.4.15 should <strong>additionally</strong> add these lines to the lines from above:</p>
<div class="Source Java"><pre>xstream.denyTypes(new String[]{ "sun.awt.datatransfer.DataTransferer$IndexOrderComparator", "sun.swing.SwingLazyValue", "com.sun.corba.se.impl.activation.ServerTableEntry", "com.sun.tools.javac.processing.JavacProcessingEnvironment$NameProcessIterator" });
xstream.denyTypesByRegExp(new String[]{ ".*\\$ServiceNameIterator", "javafx\\.collections\\.ObservableList\\$.*", ".*\\.bcel\\..*\\.util\\.ClassLoader" });
xstream.denyTypeHierarchy(java.io.InputStream.class );
xstream.denyTypeHierarchy(java.nio.channels.Channel.class );
xstream.denyTypeHierarchy(javax.activation.DataSource.class );
xstream.denyTypeHierarchy(javax.sql.rowset.BaseRowSet.class );
</pre></div>
    <p>Users of XStream 1.4.14 and 1.4.13 should <strong>additionally</strong> add these two lines to the lines from above:</p>
<div class="Source Java"><pre>xstream.denyTypes(new String[]{ "javax.imageio.ImageIO$ContainsFilter" });
xstream.denyTypes(new Class[]{ java.lang.ProcessBuilder.class });
</pre></div>
    <p>Users of XStream 1.4.12 to 1.4.7 who want to use XStream with a blacklist will have to setup such a list from
    scratch:</p>
<div class="Source Java"><pre>xstream.denyTypes(new String[]{ "javax.imageio.ImageIO$ContainsFilter", "sun.awt.datatransfer.DataTransferer$IndexOrderComparator", "com.sun.corba.se.impl.activation.ServerTableEntry", "com.sun.tools.javac.processing.JavacProcessingEnvironment$NameProcessIterator" });
xstream.denyTypes(new Class[]{ java.lang.ProcessBuilder.class, java.beans.EventHandler.class, java.lang.ProcessBuilder.class, java.lang.Void.class, void.class });
xstream.denyTypesByRegExp(new String[]{ ".*\\$ServiceNameIterator", "javafx\\.collections\\.ObservableList\\$.*", ".*\\.bcel\\..*\\.util\\.ClassLoader", ".*\\$GetterSetterReflection", ".*\\$LazyIterator", ".*\\$PrivilegedGetter" });
xstream.denyTypeHierarchy(java.io.InputStream.class);
xstream.denyTypeHierarchy(java.nio.channels.Channel.class);
xstream.denyTypeHierarchy(javax.activation.DataSource.class);
xstream.denyTypeHierarchy(javax.sql.rowset.BaseRowSet.class);
</pre></div>
	<p>Users of XStream 1.4.6 or below can register an own converter to prevent the unmarshalling of the currently
	know critical types of the Java runtime. It is in fact an updated version of the workaround for CVE-2013-7285:</p>
<div class="Source Java"><pre>xstream.registerConverter(new Converter() {
  public boolean canConvert(Class type) {
    return type != null
      &amp;&amp; (type == java.beans.EventHandler.class || type == java.lang.ProcessBuilder.class || type == java.lang.Void.class || void.class
        || type.getName().equals("javax.imageio.ImageIO$ContainsFilter") || type.getName().equals("sun.awt.datatransfer.DataTransferer$IndexOrderComparator") || type.getName().equals("com.sun.corba.se.impl.activation.ServerTableEntry") || type.getName().equals("com.sun.tools.javac.processing.JavacProcessingEnvironment$NameProcessIterator")
        || type.getName().matches("javafx\\.collections\\.ObservableList\\$.*") || type.getName().matches(".*\\$ServiceNameIterator")  || type.getName().matches(".*\\$GetterSetterReflection") || type.getName().matches(".*\\$LazyIterator") || type.getName().matches(".*\\.bcel\\..*\\.util\\.ClassLoader")
        || java.io.InputStream.class.isAssignableFrom(type) || java.nio.channels.Channel.isAssignableFrom(type) || javax.activation.DataSource.isAssignableFrom(type) ||javax.sql.rowset.BaseRowSet.isAssignableFrom(type)
        || Proxy.isProxy(type));
  }

  public Object unmarshal(HierarchicalStreamReader reader, UnmarshallingContext context) {
    throw new ConversionException("Unsupported type due to security reasons.");
  }

  public void marshal(Object source, HierarchicalStreamWriter writer, MarshallingContext context) {
    throw new ConversionException("Unsupported type due to security reasons.");
  }
}, XStream.PRIORITY_VERY_HIGH);
</pre></div>

  </body>
 </html>
